Reliance interop involving Ribbon QSBC, PSX Redirector and Ribbon Protect

Document Overview

This document outlines the configuration best practices for the Ribbon QSBC when deployed with Ribbon PSX (Redirector) and Ribbon Protect for Value-Based Routing (VBR) and Standard Routing.

Ribbon QSBC​ is a network element deployed to protect​ ​SIP-based Voice over Internet Protocol​ (VoIP) networks. ​Early deployments of SBCs were focused on the borders between two service provider networks in a peering environment. This role has now expanded to include significant deployments between a service provider's access network and a backbone network to provide service to residential and enterprise customers. ​

Ribbon Protect provides a single view of the end-to-end network, critical for UC threat detection, fraud management, and network operations. 

Ribbon PSX Ribbon's centralized policy and routing solution (PSX) provides a way to manage the security, complexity, and cost of routing calls across any operator's network.

This guide contains the following sections: 

• Section A: QSBC Configuration
  
  • Captures general QSBC configurations for Interop with PSX and Ribbon Protect.
    

• Section B: PSX Redirector Configuration

  • Captures the PSX Redirector configuration required for QSBC routing

  • Captures the PSX to Ribbon Protect interconnection related configuration

  • Captures PSX LCR Routing
• Section C: Ribbon Protect Configuration
  • Captures the configuration between QSBC and Ribbon Protect
    

Scope

It is not the goal of this guide to provide detailed configurations that will meet the requirements of every customer. Use this guide as a starting point and build the QSBC, PSX, Protect product's configurations in consultation with network design and deployment engineers. 

Audience

This is a technical document intended for telecommunications engineers with the purpose of configuring Ribbon QSBCs, PSXs and Protect. Steps will require navigating the product guide as well as the operations guide. Understanding the basic concepts of TCP/UDP, IP/Routing, and SIP/RTP is needed to complete the configuration and any necessary troubleshooting.

Product and Device Details

The sample configuration in this document uses the following equipment and software:

Network Topology Diagram

The following diagram shows the deployment topology.

The following diagram shows connectivity between QSBC, PSX and Ribbon Protect.

In the sample flow, QSBC1 needs to route the calls further based on QOS/LCR values collected by Ribbon Protect and used by PSX Redirector.

Section A: QSBC Configuration

• Create as many EP as required including one EP (type SIPGW) towards UAC, one EP (type SIPPROXY) towards PSX Redirector, and a few EPs (type SIPGW) towards the next hop QSBCs or UASs.
• Create media-related configuration on QSBC and enable the generation of QOS parameters on QSBC CDRs with the command "nxconfig.pl -e mqm -v 1".
• For ingress TG-based routing, refer to "42: Trunk group Support" in the 9.4 QSBC Operations guide.
• For sending TGRP, DTG, OTG parameters in the egress INVITE, refer to "42.7: Support for trunk group context and RFC 4904" and "42.4: Configuring trunk group endpoint options" in the 9.4 QSBC Operations guide.
• No extra configuration is required on QSBC for connection to Ribbon Protect. Ribbon Protect fetches CDRs when configuration is complete on the Ribbon Protect side.
• Refer to the QSBC Operations guide for any other specific or basic configuration.

Q21 Sample Configuration

VNET Configuration

A signaling VNET (virtual network) is the combination of a physical interface, a gateway IP address (router), and an optional VLAN (virtual local area network) ID.

cli vnet add v1
cli vnet edit v1 gateway 10.34.92.1 ifname eth2
cli vnet add v2
cli vnet edit v2 gateway 10.34.94.1 ifname eth3

REALM Configuration

Realm is a logical service entry point for other devices to connect to the SBC. (A realm on the SBC is not synonymous with a SIP realm.)

For calls to connect successfully, you must have at least one realm configured on your system.

These refer to SIP Signaling IPs of QSBC towards various peers including SIP suppliers and SWe for Telstra.

cli realm add SYDPQ21LABVFNZREALM
cli realm edit SYDPQ21LABVFNZREALM vnet v1 rsa 10.34.92.166 mask 255.255.254.0 emr alwayson imr alwayson medpool 1

cli realm add GVPSYDPQFLEXLAN394REALM
cli realm edit GVPSYDPQFLEXLAN394REALM vnet v1 rsa 10.34.92.167 mask 255.255.254.0 emr alwayson imr alwayson medpool 1

cli realm add GVPLABPMPLSGVOIPCUSTREALM
cli realm edit GVPLABPMPLSGVOIPCUSTREALM vnet v1 rsa 10.34.92.168 mask 255.255.254.0 emr alwayson imr alwayson medpool 1

cli realm add LABGIA210REALM
cli realm edit LABGIA210REALM vnet v1 rsa 10.34.92.169 mask 255.255.254.0 emr alwayson imr alwayson medpool 1

cli realm add TCISYDLSWELABREALM
cli realm edit TCISYDLSWELABREALM vnet v2 rsa 10.34.94.166 mask 255.255.254.0 emr alwayson imr alwayson medpool 2

cli realm add GVPLABPMPLSGVOIPCUSTREALM2
cli realm edit GVPLABPMPLSGVOIPCUSTREALM2 vnet v2 rsa 10.34.94.167 mask 255.255.254.0 emr alwayson imr alwayson medpool 2

cli realm add PSX
cli realm edit PSX vnet v2 rsa 10.34.94.168 mask 255.255.254.0 emr alwayson imr alwayson medpool 2

End Point Configuration

PSX EndPoints (EPs) to send INVITE and receive 300 response

cli iedge add SYDLPSXLAB01EP 0
cli iedge edit SYDLPSXLAB01EP 0 realm PSX static 10.54.181.13 sip enable type sipproxy dtg SLPSXLBPAD01 use4904tg disable setdesttg disable  vendor generic 

cli iedge add SYDLPSXLAB01EP 1 
cli iedge edit SYDLPSXLAB01EP 1 realm PSX static 10.54.181.13 sip enable type sipproxy use4904tg disable setdesttg disable vendor generic cp PSX01CP

SIP Supplier EPs

F1.1 EP for PSX dedicate Realm (Existing EP) REALM: 10.54.92.166

cli iedge add SYDPQ21LABVFNZEP 0
cli iedge edit SYDPQ21LABVFNZEP 0 realm SYDPQ21LABVFNZREALM static 10.54.81.11 sip enable type sipgw cp TEAMS01CP newsrcdtg SLPSXLBPAD01 use4904tg disable vendor generic 
cli iedge edit SYDPQ21LABVFNZEP 0 newsrcitg "SLVODAFNZL01"

B4-GW1 (Existing EP) REALM: 10.54.92.167 with 4904 disabled

cli iedge add SYDPQ21LABVFNZEP 1
cli iedge edit SYDPQ21LABVFNZEP 1 realm GVPSYDPQFLEXLAN394REALM static 10.54.81.11 contact 10.54.81.11:8012 sip enable type sipgw dtg SLVODAFNZL01 tg SLVODAFNZL01 use4904tg disable vendor generic 

F1.2 EP for Selection of Ingress via DNIS REALM: 10.54.92.168

cli iedge add SYDLSIPLAB02EP 0
cli iedge edit SYDLSIPLAB02EP 0 realm GVPLABPMPLSGVOIPCUSTREALM static 10.54.81.12 contact 10.54.81.12:8012 sip enable type sipgw cp TEAMS02CP dtg SLVODAFNZL02 tg SLVODAFNZL02 use4904tg disable setdesttg enable vendor generic

F1.3 EP for Selection of Ingress via sourceTG=SLVODAFNZL03 (REALM: 10.54.92.168) with 4904 enabled

cli iedge add SYDLSIPLAB02EP 1
cli iedge edit SYDLSIPLAB02EP 1 realm GVPLABPMPLSGVOIPCUSTREALM static 10.54.81.12 contact 10.54.81.12:8014 sip enable type sipgw newsrcdtg SLPSXLBPAD01 dtg SLVODAFNZL03 tg SLVODAFNZL03 use4904tg enable vendor generic

B4-CSF2

cli iedge add SYDLSIPLAB02EP 2
cli iedge edit SYDLSIPLAB02EP 2 realm GVPLABPMPLSGVOIPCUSTREALM static 10.54.81.12 sip enable type sipgw dtg SLGVQ21PAD02 use4904tg disable vendor generic

B4-CSF1 (Existing EP)

cli iedge add GVMSYDPGIASYDLP01 1
cli iedge edit GVMSYDPGIASYDLP01 1 realm LABGIA210REALM static 10.54.81.13 sip enable type sipgw dtg SLGVQ21PAD01 use4904tg disable vendor generic

F4, B1 (EP for 3XX to LAB SWE1) 

cli iedge add SYDLSWELAB01EP 0
cli iedge edit SYDLSWELAB01EP 0 realm PSX static 10.54.81.66 sip enable type sipgw newsrcdtg SLPSXLBPAD01 use4904tg enable vendor generic setdesttg enable URI 10.54.81.66

F4-B1 (EP for 3XX to LAB SWE2) 

cli iedge add SYDLSWELAB02EP 0
cli iedge edit SYDLSWELAB02EP 0 realm TCISYDLSWELABREALM static 10.54.81.67 sip enable type sipgw newsrcdtg SLPSXLBPAD01 use4904tg enable vendor generic setdesttg enable URI 10.54.81.67

Sample Calling Plans

INGRESS FROM SUPPLIER CALLING PLAN

cli cr add TEAMS09980315INGCR
cli cr edit TEAMS09980315INGCR calltype origin dest 09980315 prefix 64*09980315
cli cp add TEAMS02CP TEAMS09980315INGCR
cli iedge edit SYDLSIPLAB02EP 0 cp TEAMS02CP

EGRESS TO PSX CALLING PLAN
(For 64* prefix numbers routed to PSX redirector)

cli cr add TEAMS09980315EGRCR
cli cr edit TEAMS09980315EGRCR calltype dest dest 64*09980315 prefix 0998031512345
cli cp add PSX01CP TEAMS09980315EGRCR
cli iedge edit SYDLPSXLAB01EP 1 cp PSX01CP

Link Calling Plan with MULTIPLE Calling Route

cli cr add TEAMS09980316INGCR
cli cr edit TEAMS09980316INGCR calltype origin dest 09980316 prefix 09980316
cli cp add TEAMS01CP TEAMS09980316INGCR

cli cr add TEAMS0998032INGCR
cli cr edit TEAMS0998032INGCR calltype origin dest 0998032 prefix 0998032
cli cp add TEAMS01CP TEAMS0998032INGCR

cli cr add TEAMS099803301INGCR
cli cr edit TEAMS099803301INGCR calltype origin dest 099803301 prefix 099803301
cli cp add TEAMS01CP TEAMS099803301INGCR

cli cr add TEAMS099803302INGCR
cli cr edit TEAMS099803302INGCR calltype origin dest 099803302 prefix 099803302
cli cp add TEAMS01CP TEAMS099803302INGCR

cli cr add TEAMS0998034INGCR
cli cr edit TEAMS0998034INGCR calltype origin dest 0998034 prefix 0998034
cli cp add TEAMS01CP TEAMS0998034INGCR
cli iedge edit SYDPQ21LABVFNZEP 0 cp TEAMS01CP

Section B: PSX Configuration

PSX Redirector related configuration

• The PSX requires a SIP server entry created with QSBC SIP IP towards the PSX side.
• The PSX requires a Trunk Group created with SIP server created in the previous step. If this step is missed, PSX uses the default SIP server entry, "DEFAULTSIPSERVER".
• The PSX Trunk Group requires a Feature Control Profile with "IP Protocol Flags" enabled, and "Support Domain Name in 300 Contact" enabled with the PSX processing mode set to "Redirector".
• Additionally, if required, the Feature control profile options can have "Process TGRP", "Process Trunk-context", "Process Originating Trunk Group And Trunk-context over OTG" enabled.
• The PSX Trunk Group can have IP Signaling profile with "Destination Trunk Group Options" set to either "Include DTG" or "Include Tgrp with domain name" based on customer requirement.
• The PSX Trunk Group can have IP Signaling profile with "Destination Trunk Group Options" set to either "Include DTG" or "Include Tgrp with domain name" based on customer requirement.
• Additionally, if required, IP Signaling profile can have "Originating Trunk Group Options" set to either "Include DTG" or "Include Tgrp with domain name" based on customer requirement.
• The PSX can have any kind of routing including standard routing based on trunk group or destination number with a Routing Label containing all the routes. Each route requires a destination "SIP server" and "Trunk Group". SIP server can have FQDN configured or IP address according to the requirement.
• The PSX Ingress Trunk Group requires the "Use IPTG Routing" option to be enabled.
• The PSX can return up to 10 Routes only in 300 Response when acting as a redirector.

PSX LCR configuration

This section describes the implementation of the LCR feature in the PSX for this project.

1.1 Description

LCR routing chooses a destination routing path based on the cost that provides the most savings. LCR makes the selection based on rate lists provided by one or more vendors. LCR must provide the least expensive way to route a call.

Vendors publish rate sheets to network operators. Network operators load and manage these rate sheets. The rate sheet data along with Quality of Service information is used to provide value-based routing to customers of the network operators. The rate sheet life cycle management includes parsing the rate sheets using their metadata template files, storing them in a local database to view them, pushing the optimized intermediate form rate sheets to PSX primary and secondary boxes, and undoing or rolling back loaded rate sheets. Routing of calls from customers to vendors relies on the vendor rates, offers agreed to with customers, exception handling, and call quality (or QoS).

Network Operators provide call routing services to their customer by using services from its vendors. Suppliers or vendors supply rate sheets, whereas customers are associated with Offer Bundles provided by the reseller. Network Operators offer bundled services to customers, which include a sell rate sheet. Offer Bundles can be generic and offered to multiple customers, or they can be made customer-specific to handle specific customer agreements. The TG and other call processing elements such as the carrier and subscribers are used to uniquely identify a customer.

A vendor contains a rate sheet and a set of egress trunk groups. The network operator offers multiple services to customers based on cost and quality. These services are referred to as Offers. Each Offer comes with a sell rate sheet that defines the cost TOTs and a set of quality parameters that define the expected quality of the offer. For example, a 'Premium' offer may cost more and has high quality, whereas a 'Silver' offer may be cheaper, but with a significantly lower quality compared to the Premium quality.

The network operator also picks certain vendors and associates them with the offer. This information may or may not be available to the customer. The association indicates that calls of customers using an offer will only be routed to the associated vendors taking cost and quality into account.

1.1.1 Quality of Service

Quality of Service (QoS) is a combination of various parameters measurements which impact the call and voice quality. QoS depends on terminating vendor trunk groups. The QoS parameters are name-value pairs from the LCR perspective. The service provider can provision any number of factors or parameters.

QoS plays a major role in an Offer. A Premium package, for example, can come with a better quality of service as compared to, for example, a Silver package. Each package has its defined QoS parameter ranges. There is an expected QoS of the Premium Package Offer along with the cost as defined by the Sell Rate Sheet. The Network Operator must make sure that the vendors added to the offer are meeting the defined QoS.

QoS parameters are defined at a global level in the system and the defined QoS parameters can be chosen and combined using AND and OR logical operations with a subset of range values for computation purposes.

An Offer is associated with a QoS profile. If it is not associated (NULL profile), then no QoS checks happen for that Offer.

Each QoS profile contains a set of rules. Each rule has an order. The rules are evaluated based on the order. Each rule contains one or more QoS parameters interconnected with AND operations.

Each QoS parameter range must be defined and be within the range defined for that parameter at the global or system level. The rules within a given profile are interconnected with the OR operation. If a rule is evaluated to TRUE then no further evaluations are necessary and the QoS standards are met. If it is evaluated to FALSE then the next rule is evaluated. If all rules in the given profile are exhausted and all of them yielded FALSE, then it indicates failure to match set standards of QoS and results in ignoring the route associated with that egress TG.

8 QOS  Parameters for LCR or VBR are given below

1. AHCT: Average Call Hold Time
2. ASR: Answer Seizure Ratio  (Call Attempts Vs Completion)
3. JITTER: Jitter is the variation in delay of received packets
4. MOS: Mean Opinion Score
5. MOU: Minutes of Usage
6. NER: Network Effectiveness Ratio. It's similar to ASR but excludes customer behavior & terminal behavior like user busy or no answer
7. PDD: Post Dial Delay. It's the time between end of dialing & beginning of ringing
8. PLP: Packet Loss Percentage

1.1.2 Vendor

Each vendor has a rate sheet and expected or committed quality of service (based on a bilateral agreement). Each vendor owns one or more trunk groups. A vendor may be part of one or more offers. Each trunk group may be associated with the QoS parameters, which is used in rule computation to assess, whether the TG meets the quality standards defined at the Offer level. For example, consider Vendor A is put into a Premium Package. If one of the trunk groups, TG1, owned by the vendor has an extended PDD, then the network operator can manually update the PDD QoS parameter on that TG. This value may result in failure of some or all the QoS rules defined at the Offer level for calls attempting to go over TG1. As a result, the TG1 may not be considered for routing, because it may not meet the quality requirements of the Premium Offer. But, the same trunk group QoS range may be meet the requirements for the Wholesale Package.

If no QoS parameter is set, then a call is routed on a trunk group without any QoS checks. The QoS name-values must be provisioned by the Network Operator using the LCR provisioning GUI or CLI mechanisms.

A report which details trunk groups that have QoS parameters set is available.

1.1.3 Customer

A customer subscribes to an Offer provided by the Network Operator. A customer may subscribe to more than one offer in certain scenarios. For example, a customer may purchase a Premium package to handle specific calls; for top management callers, and Silver package for all other callers in the company.

The customer expects the quality of service to be on par with the defined ranges as part of the 'Offer'. The QoS parameters are defined as part of the QoS profile and associated with an Offer. QoS parameter values can be set at the Egress Trunk Group Level. It is the responsibility of the Network Operator to provision the QoS values appropriately on Trunk Groups.

1.1.4 Customer Identification Criteria

All data necessary to identify a customer and an offer is available in a table called VBR_CUSTOMER_IDENTITY. The ingress call processing elements which identify a customer is a part of this table. The call processing element types supported are currently limited to the following (ordered by precedence – high to low):

• Subscriber
• Trunkgroup
• Gateway
• Carrier

The Subscriber value may contain a prefix instead of full number. There is no primary key for this table. A unique index is needed on all columns to avoid duplicate rows. The value Sonus_NULL is used if no value is provisioned.

1.1.5 Profit Margins

From a service perspective a Network Operator needs to guard against losing money or control how much money they are willing to lose. This directly affects the routing decision for a call. A Network Operator can route calls for certain customers with a small or even negative profit margin but can drop calls for other Customers if the calls incur a loss. It is critical for the LCR system to support a mechanism for profit protection for Network Operators.

Margin is defined on an Offer by the Network Operator. A service provider can for example define a margin as at least X% profit, no loss routing, or a Y% loss.

Network Operators can override the margin defined at the offer level by setting a margin at the customer-offer level.

1.1.6 Margin Profile

A margin profile is associated with either an Offer or with a Customer in the context of an offer. The margin is the same for all the dial codes in the sell rate sheet associated with the offer. If the margin profile is not associated with an Offer or customer, then the call is completed irrespective of price. The sell rate sheet and margins are ignored, in this case. The margin profile contains a percentage. If the percentage is positive it indicates a profit, if it is negative it indicates a loss.

For example, if the percentage is +20%, it indicates the profit has to be at least 20%. The margin profile then ignores all the routes where the cost is below the 20% margin. If the sell rate sheet indicates the price for the 781123 dial code as 0.5, then the vendor rate sheet entries prices are <= 0.4.

If the percentage is -20%, the service provider is willing to take a loss of at most 20%. So the margin profile ignores the routes where the cost is above 20% loss. If the sell rate sheet indicates the price for the 781123 dial code as 0.5, then the vendor rate sheet entries prices are <= 0.6.

The gain or loss percent value is computed from the sell rate sheet.

Two customers may sign up for same Offer (for example, Premium), the network operator can set up different margins for these customers by overriding the margin profile defined at the offer level.

1.1.7 Minutes of Use

Volume or Dollar Commitment

This is a commitment from the Buy Side to the Sell Side to route the committed amount of call in terms of volume, that is Minutes of Use, or in terms of dollar amount paid to the Sell Side, over a specified time period. The time period is typically on a monthly basis. Some Network Operators may, once the quota committed to a Vendor is filled before the month end, temporarily suspend call termination towards the vendor if a cheaper vendor can be used to terminate the calls until the start of the next month.

Sonus LCR provides place holders for minutes of use. As part of the vendor data, the "minutes of use" flag is turned ON. When this flag is turned ON, it influences the routing. If MOU is turned ON, then the vendor is used as top route irrespective of cost, but the cost has to be within the margins defined. This means when a vendor has a dial code which can complete the call, it need to be chosen (based on if the vendor is part of the Offer) irrespective of cost. If more than one vendor has the MOU agreement, then the vendor priority determines which vendor to choose first in call completion. QoS filtering is also applied on the MOU vendors.

1.1.8 Exceptions or Black Lists

Some of the dial codes for specific suppliers be blacklisted for all customers or for a specific customer. A customer can request a supplier to be put in black list. An offer may be associated with zero or more customers. Each customer has the ability to put certain suppliers or dial codes in the black list.

The exceptions contain type and scope. The scope indicates the scope of the exception (ALL, Offer Id, or Customer Id). Each type may have one or more values. The following types and values are supported. If the CustomerId is Sonus_NULL, it impacts all customers.

1.2 Rate Sheet

Rate sheets come in various formats and flavors. The Rate sheet from each vendor follows a different template. The Rate sheet template defines the metadata and also provides parsing instructions.

• A generic rate sheet template is defined, which captures various permutations and combinations of rate sheets.
• Each rate sheet must be accompanied by a template; otherwise the rate sheet cannot be parsed.
• Vendors can reuse the templates for their rate sheets unless the format is changed. A format change triggers changes to the template file.
• The rate sheet id, name, effective, and expiry (if any) dates must be available before starting the parsing process. If the parsing produces errors, you must fix the errors before retrying the operation.
• These errors cannot be tracked during pre-processing. If the parsing is successful, an intermediate file is created.
• Sometimes the vendor has to be contacted for clarifications to fix the rate sheet before proceeding further.

Loading a Rate sheet involves:

• Parsing the Rate sheet using template file and generating an intermediate rate sheet file. The intermediate format is a common format for all the rate sheets.
  Loading the intermediate Sonus LCR rate sheet file into the Database.
• The rate sheet is in a comma separated (.csv) file format.
• The rate sheet parser uses the rate sheet along with the template as input. The parser reads the rate sheet template and builds an internal data structure. It then processes the rate sheet using the translation semantics gathered from the template file and stored in the internal data structure.
• The parser creates the intermediate Sonus LCR Rate sheet file, which you can load into the PSX Database using the rate sheet loader program.

Load Rate Sheet to the PSX:

The following example shows the generation of the PSX loading the “Rate Sheet”.

Rate sheet example (Viettel-P.csv):

Template example (Viettel-P_Template.dat):

Save both files in a directory readable for the “ssuser”.

Log in to the PSX as ssuser and execute the following commands:

This command generates the intermediate rate sheet (intermediate_vendor01.dat).  This rate sheet is loaded into the PSX later.

lcrrsprsr -t <path>/<template file> -i <path>/<rate sheet file> -o <path>/<intermediate file>

To upload the intermediate file to the PSX, run the following command:

lcrrsldr -l <path>/<intermediate file>

To load an offer rate sheet, change the type to “OFFER” in the business section. The rest of the template remains the same.

To generate the intermediate rate sheet, run the following command:

lcrrsprsr -t <path>/<template offer file> -i <path>/<rate sheet offer file> -o <path>/<intermediate offer file> -ofr offer_id

To load the rate sheet for the offer:

lcrrsldr -l <path>/<intermediate offer file>

1.3 LCR Currency

Use this screen to define the currency data of the rate sheets.

1.4 Vendor Routing Label

This Routing Label contains the routes associated with the vendor which the PSX returns in the policy response to the SBC/GSX. The routes selection in the action frame notifies the PSX that a route must be returned as part of the response. Each combination of the SBC/GSX node / Trunk Group (Egress TG) pair must be added as a route option in the Routing Label.

For this design, the following routing labels provide an example of the design. Appropriate routing labels are created in actual implementations.

The following are the routing labels that are being used for the vendor associated with the routing label.

1.5 LCR Vendor

Create a Vendor entry using the LCR Vendor screen. Make sure you provision the Vendor Id (for example, VIETTEL_PREMIUM), a Routing Label Id (for example, VIETTEL_PREMIUM_RL) that is associated with the vendor, and a Currency Code (for example, USD).

To import Vendor Rate Sheets, use the rate sheet parser and loader tool to load vendor rate sheets. The vendor must exist in database for the data to be imported.

lcrrsldr -l <path>/<intermediate file>

1.6 LCR Offer

Create an Offer entry using the LCR Offer screen. Set the Offer Id (for example, PREMIUM). If needed, create Offers and provide the Offers to the customers. Offers can contains a sell rate sheet and a set of QoS parameter values. The following is an example of an offer for US customers.

The example above contains 3 vendors.

To import Offer Rate Sheets, use the rate sheet parser and loader tool to load offer rate sheets.

The Offer must exist in database for the data to be imported. Loading offer rate sheet is optional and is necessary only when margins are a consideration.

lcrrsldr -l <path>/<intermediate offer file>

There are 4 types of LCR offers in this initial deployment:

1.7 LCR Customer

The following is an example of an LCR Customer:

Set the Customer Identification Criteria (Call Processing Element Type). The CPE types are Trunk Group, Gateway, Carrier, or Subscriber.

Associate Offers with a customer. For this deployment, Carrier (007) is an example for PREMIUM (Premium Customers).
There are 4 types of LCR customers in this initial deployment:

1.8 Additional Information

For the LCR deployment, the following additional entity is created:

1) Routing Label = LCR_RL

The routing label above is required for LCR configurations with LCR selected as the action.

2) Standard Route

The standard route above is an example of a route with an assigned LCR routing label. This standard route affects all calls in the 007partition. The LCR_RL routing label means that the PSX will process all calls matching the criteria as an LCR call.

1.9 Create LCR QOS

Use this to create minimum and maximum values  for each QOS parameter as shown below in the sample configuration:

Create LCR QOS

1.10 LCR Trunk Group QOS

PSX uses this table to update the QOS values for every TG of QSBC2 and QSBC3 in this example.

This table is also used to select or reject that TG while returning routes in the PSX Response in 300 Multiple Choice.

Create LCR Trunk Group QOS

PSX to Ribbon Protect Interconnection

• PSX can fetch QOS KPI values (.csv files) from Ribbon Protect with the following interconnect configuration.

Configuring SSH for PSX and Ribbon Protect's Dig Core Pod 

Prerequisites

Ensure that you have the following details of the Ribbon Protect's Dig Core Pod:

• IP Address: Dig Core IP 
• Login ID/Password of an account (dig core IP): Default user credentials: pstk / pstk
• Directory where the KPI files are kept and updated frequently with .csv extension. The default is /stats/scoring/vbr

Procedure Steps

1. You must manually complete this configuration before the file transfer begins on both Active and Standby machines.

• Login to the Master PSX as an ssuser.
• Run the following command to generate the Public and Private keys:

$ ssh-keygen

The command above generates two key files:

id_rsa which is a Private Key
id_rsa.pub which is a Public Key

• Transfer the public key id_rsa.pub file to the Ribbon Protect's Dig Core Pod under path /home/pstk/.ssh/

$scp /export/home/ssuser/.sshid_rsa.pub pstk@DigCoreIP:/home/pstk/.ssh/id_rsa.pub

• Ensure that the rsync utility is available under /usr/local/bin. If not, create a soft link using the following command:

ln -s /usr/bin/rsync /usr/local/bin/rsync

This is needed for the Solaris PSX Master to work with Dig Core Pod.

• Append the transferred Public Key from file id_rsa.pub on the destination Protect's Dig core machine's authorized_keys file (/home/pstk/.ssh/authorized_keys)
  Example:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA2t+bzQrc7iaiIZuxaoLaP2p7QWDQkMuNhMzh4KlqMADrnUl0Jgaq7tMYvBbEpV2a8DbOqZKBahqz/DgKZNW3dwPcZ6GsbGVGRfOyuHbDdR+A/2SGXw1CqmMMBx/5eU0tFLhZv+qnY/BpZaIS9hc/xbhEQdBwRmcHoS0bCuQkK+q5+nbCxKV+EcleHqFG3i9vVaOF5E6fNlxSHGdtCA/K78kIPSR2zye9AmfrqsubMUqxX+4VpjxL8gfL5/X27Nsp0LhOCbBq4Mw9MbaPPcg6qTOs4WZvCeEmWsLEYQnRfhp6WNIOG7OYOEowCOJAfbTCXYphzNYSUXj01w+nZ4JQ== ssuser@mypsx

where mypsx is the Hostname of the Master PSX machine.

2. Set up KPI transfer and processing. 

This is a one-time configuration to complete the setup process.

• On PSX master, run the following command as an ssuser from the path /export/home/ssuser/SOFTSWITCH/BIN.

$setupnextxkpi.sh <Dig Core IP address or host name> <wait time before raising trap>

Example

$setupnetxkpi.sh 10.6.30.128 10

where
10.6.30.128 is the IP Address of the Dig core Pod.
10 is the wait time before raising trap

• Stop the scripts or kpinonstop.sh or kpisync.sh if they are running.
• Update the script kpinonstoptemplate.sh with the Dig Core Pod IP Address and the time limit to wait before raising a trap.
• Perform this step if you are setting up the configuration for the first time.
• Verify the ssh connection from the PSX Primary and NetScore

$ ssh -i /export/home/ssuser/.ssh/id_rsa pstk@DigCoreIP
Are you sure you want to continue connecting (yes/no)? yes

• Enter Yes. Once the Dig Core Pod is connected, you do not need to re-enter your password during each KPI transfer.

3. Restart the Softswitch on the Master PSX.

• To stop the softswitch, log in and run the following command:

cd /export/home/ssuser/SOFTSWITCH/BIN
./stop.ssoftswitch

• To start the softswitch, log in and run the following command:

cd /export/home/ssuser/SOFTSWITCH/BIN
./start.ssoftswitch

The softswitch starts the kpinonstop.sh (if exists) in the background and stops kpinonstop.sh, kpisync.sh and lcrpildr if they are running before invoking kpinonstop.sh.
The softswitch stops kpinonstop.sh, kpisync.sh and lcrpildr if they are running.
This ensures that the KPI transfer functions long as the softswitch is up and running

Section C: Ribbon Protect Configuration

Log in to Ribbon Protect GUI via the web browser with its Management (MAG) IP.

Go to System -> Add-on Manager -> Q20-Q21 Live Base KPIs -> Click "Deploy Add-on" for deploying the Add-on for VBR.

Add-on Q20-21 Live Base KPIs

Go to System -> Add-on Manager -> Q20-Q21 Live Extended KPIs -> Click "Deploy Add-on" for deploying the Add-on for VBR.

This add-on includes additional aggregations by gateway and also by static endpoint to compute codec KPIs, ISDN cause code KPIs, SIP Response Code KPIs, and QoS KPIs by Codec.

Q20-Q21 Live Extended KPIs

Go To Applications → Discover → KPI Sets → "Run" (if not in the run state).

Download CSR

Aggregation service for QSBC and Core SBC set to 5 mins interval (System -> Global Settings -> Aggregation Service -> Q20/21

Enable "Value based Routing" by configuring "min bid count" to "5" (or any number according to the requirement) and select "Update".

Go to Applications → Discover → Value Based Routing → Configuration.

Enable Value Based Routing

Section D: Troubleshooting Information

Troubleshooting PSX Redirector interconnection with Ribbon Protect

When Ribbon Protect, PSX and QSBCs are configured and are up and running, you can check whether PSX is pulling data from Ribbon Protect.  Access the PSX as root and check the /var/log/messages log.

If PSX successfully pulls data, you can see logs similar to the following:

Sep 19 05:44:54 STPSX02 lcrkpildr[29547]: lcrkpildr: finished kpi file (/tmp/VBR-network-15-2020-09-18Z23:35:00.csv) load at Sat Sep 19 05:44:54 2020#012.
Sep 19 05:44:54 STPSX02 lcrkpildr[29547]: lcrkpildr: loading took 0 seconds.
Sep 19 05:44:54 STPSX02 lcrkpildr[29547]: lcrkpildr: kpi file (/tmp/VBR-network-15-2020-09-18Z23:35:00.csv) load report (last updated=1600474494) - noValues=6, unchanged=70, gets=74, inserts=0, updates=4, gateway-trunkgroup not found=0, insert failures=0, update failures=0

Troubleshooting Ribbon Protect

Log in to the Ribbon Protect Internal IP and execute the following.

A) For Checking VBR/LCR data in Ale-Lcr Pod

1. To Display All running Pods

kubectl get pods -o wide 

2. To Login to Specific Pod like Ale Lcr

kubectl exec ale-lcr-5dcd76c45-qkxcb -it bash

3. Check that the VBR/LCR csv file is stored in the following path.

cd /home/lcr/

B) For Checking VBR/LCR data in Dig Core Pod

1. To Display All running Pods

kubectl get pods -o wide

2. To Login to Specific Pod like Dig Core

kubectl exec digcore-5fb8988b65-cg829 -it bash

3. Check VBR/LCR csv file stored in the following path.

cd /var/dropbox/pstk/stats/scoring/vbr

C) For Checking VBR/LCR data in Hadoop DB

Enter the following 3 commands:

kubectl exec hadoop-master-0 -it bash

su -s /bin/bash impala -c "impala-shell --ssl -k -i hadoop-data-0.hadoop.default.svc.cluster.local"

use sensorstore;

1.  To Check the Quantity of Q21 CDRs fetched by Ribbon Protect from Q21

select count(*) from tbl_ribbonsbcqx_cdr; 

 D) For Checking VBR/LCR data in PostGres DB 

Enter the following 3 commands:

kubectl exec postgres-0 -it bash

psql -U postgres appstore;

select * from data_aggengine.tbl_kpi_qx_vbrstats_by_egress_tg;

E) For checking Ribbon Protect Log 

Log in to the Internal IP and then go to directory /flume and check the latest vigil log.

cd /flume

vi vigil-1591603823719-192.log 

There should not be any SQL exception related errors like the sample log shown below:

[2020-06-16 12:51:05,910][aggengine][ERROR][aggengine][vigil.app.common.DBActor][43]: SQLException SQL State = 08006 Error Code = 0
[2020-06-16 12:51:05,911][aggengine][ERROR][aggengine][vigil.app.common.DBActor][44]: SQLException message An I/O error occurred while sending to the backend.
[2020-06-16 12:51:05,911][aggengine][ERROR][aggengine][vigil.app.common.DBActor][45]: SQLException

Conclusion

These Application Notes describe the configuration steps required for QSBC interop with PSX Redirector and Ribbon Protect. All features and serviceability test cases were completed.